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(54) System for signatureless transmission and reception of data packets between computer 
networks 



(57) A system ioi auiomatically enciypiiriy and de- 
crypting data packet sent from a source host to a desti- 
nation host across a public internetwork. A tunnelling 
bridge is positioned ai each network, and intercepts all 
packets transmitted to or from its associated network. 
The tunnelling bridge includes tables indicated pairs of 
hosts or pairs of networks between which packets should 
be encrypted. When a packet is transmuted from a first 
host, the tunnelling bridge of that host's network inter- 
cepts the packet, and determines from its header infor- 
mation whether packets trom that host ihat are directed 
to the specified destination host should be encrypted; or, 
alternatively, whether packets from the source host's net- 
work that are directed to the destination host's network 
should be encrypted. It so, the packet is encrypted, and 
transmitted to the destination network along with an en- 
capsulation header indicating source and destination in- 
formation: eiiher source and destination host addresses, 
or the broadcast addresses of the source and destination 
networks (in the latter case, concealing by encryption the 
hosts 1 respective addresses). An identifier of me source 



networks tunnelling budge may also be included in the 
encapsulation header At the destination network, the as- 
sociated tunnelling bridge intercepts the packet, inspects 
the encapsulation header., trom an internal table deter- 
mines whether the packet was encrypted, and fiom ei- 
ther the source (host or network) address or the tunnel- 
ling bridge identifier determines whether and how the 
packet was encrypted. If the packet was encrypted, it is 
now decrypted using a key siored in the destination tun- 
nelling bridge's memory, and is sent on to the destination 
host. The tunnelling bridge identifier is used particularly 
in an embodiment where a given network has more than 
one tunnelling bridge, and hence multiple possible en- 
cryption/decryption schemes and Keys. In an alternative 
embodiment, the automatic encryption and decryption 
may be carried out by the source and destination hosts 
themselves, without the use of additional tunnelling 
bridges, in which case me encapsulation header in- 
cludes the source and destination host addresses. 
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Description 

The present invention ielai£:S"to' me held oi secure transmission oi data packets, ana in paincuiai to a new systein 
i or automatically encrypting and oecrypting data packets between sites on the Internet or other networks of computer 
5 networks. 

It is becoming incieasu'igiy useiul ioi businesses to transmit sensitive n iiomiation via networks such as me iniuinet 
horn one site to another, and concomitantly more urgent that such information be secured from uninvited eyes as it 
traverses the internetwork. At present, unsecured data is replicated at many sites in the process ol being transmitted io 
a destination site, and trade secret or other private information, unless seemed, is thereoy made available to the public. 

io it is possible for a user at the sending host to encrypt the data to be sent, and to inform the user who is to ieceive 

the data of the encryption mechanism used, along with the key necessary to decrypt. However, this requires communi- 
cation and coordinated effort on the parts of both the sending and receiving users, and often the users will not take the 
requisite trouble and the packets will go unencrypted. 

Even when these packets are encrypted, the very lact oi tneir being uansnuLieo irorn user A to usei 6 may be 

''5 sensitive, and a system is needed that will also make this inion nation private. 

Figure 1 illustrates a network ol computer networks, including networks Ni. and N'3 inteiconnecteu via a public 
network 10 (such as the Internet). When network'Nl is designed in conventional fashion, it includes several to many 
computers (hosts), such as host A and additional hosts 20 and 30. Likewise, network N2 includes host B and additional 
hosts 40 and 50, while network IM3 includes hosts 60-90. There may be many hosts on each network, ana many more 

20 individual networks than shown iieie. 

When a user at host A wishes to sund a hlo email oi the (ike to host B, me tile- i=> spin into [jackets, eaci i ui wJ ucn 
typically has a structure such as packet 400 shown in Figure 7, including data 410 and a header 420. For sending over 
the Internet, the header 420 will oe an internet protocol (IP) header containing the address of the recipient (destination) 
host B. In conventional fashion, each data packet is routed via the internetwork 10 to the receiving network N2, and 

*5 ultimately to the receiving host B. 

As indicated above, even if the user at host A encrypts the tile or data packets before sending, and usei b is equipped 
with the necessary key to decrypt them, the identities of the sending and receiving hosts are easily discernible uom the 
Internet Protocol (IP) addresses in the headers of the packets. Current internetworks do not provide an architecture or 
method for keeping this information private. More basically, they do not even provide a system for automatic encryption 

30 and decryption ot data packets sent Irorn one host to another. 

The system of the invention includes a tunnelling bridge positioned at the interlace between a private network ana 
a public network (or internetwork) tot each of a number of such private networks Each tunnelling bridge is a stand-alone 
computer with a processor and a memory, and in each tunnelling bridge's memory is a hosts table identifying which 
hosts should have their data packets (sent or received) encrypted. Alternatively, a networks table could be used, indi- 

35 eating whether data packets to and from particular networks should be encrypted; or other predetermined criteria may 
be stored that indicate whether particular data packets should be encrypted. 

.The tunnelling bridge for a given private network (or subnetwork of a private network) intercepts all packets sent 
outside the network, and automatically determines from the tables whether each such packet should be encrypted. It 
so, then the tunnelling bridge encrypts the packet using an encryption method and key appropriate for the destination 

40 host, adds an encapsulation header with source and destination address information (either host address or IP broadcast 
address for the network) and sends the packet out onto the internetwork. 

At the destination host, another tunnelling bridge intercepts all incoming data packets, inspects the souice and 
destination address information, and determines from its local hosts (or networks) table whether the packet should be 
decrypted, and it so ; by what method and using what key. The packet is decrypted, it necessary., and sent on to the 

45 destination host. 

In this way, all messages thai aie predetermined to iequire enciypuon, e g all messages irorn a given host a to 
another host B, are automatically encrypted, without any separate action on the pan ot the usei. In this way : no one on 
the public internetwork can determine the contents of the packets. If the encapsulation header utilizes the network IP 
source and destination addresses, with the source and destination host addresses encrypted, then the host identities 
so are also concealed, and an intervening observer can discern only the networks' identities. 

The encapsulation header may include a field with an identifier of the source tunneling oiioye Tins is pamcuiaiiy 
useful if more than one tunnelling bridge is to be used tor a given network (each tunnelling bridge having different 
encryption requirements and information), and in mis case the receiving tunnelling bridge decrypts the data packets 
according to locally stored information indicating the encryption type and decryption key for all packets coming irorn the 
55 source tunnelling bridge. 

By way of example oniy, speenic ernoodiments ot tne present invention will now be descriued. wim leioience to me 
accompanying drawings, in which: - 

Figure! is a diagram of a network ot computet networks in conjunction with which the system oi tnepiesem invention 
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may be used 

Figure 2 is a block diagram of a host computer A on computer network N1 shown in Figure 1 . 

Figure 3 is a diagram of a network of computer networks incorporating tunnelling bridges according to the present 
invention. 

Figure 4 is a block diagram of several tunnelling bridges of the presem invention irv a network of computer networks 
N 1 -N3 as shown in Figure 3. 

Figures is ^ diagram of another configuration of networks incorporating tunnelling bridges according to the present 
invention. 

Figure 6 is a flow chart illustrating the method of signatureless tunnelling of the present invention. 
Figure 7 illustrates a conventional data structure for a data packet. 

Figures 8-1 1 illustrate modified data structures for use in different embodiments of the system of the invention. 
Figure 1 2 is a block diagram of a network of computer networks including two tunnelling bridges of the invention on 
a single computer network. 

The system of the present invention is designed to be implemented in existing computer networks, and in the pre- 
ferred embodiment uses the addition of a tunnelling bridge at junctions between local computer networks and public or 
larger-scale networks such as the Internet. The mechanisms for carrying out the method of the invention are implemented 
by computers acting as these tunnelling bridges, incorporating program instructions stored in memories of the tunnelling 
bridges and appropriate (standard) network connections and communications protocols. 

Figure 3 shows a network 100 of networks N1, N2 and N3 according to the invention, where each network includes 
a tunneling bridge -- TBI, TB2 and TB3, respectively - which intercepts all data packets from or to the respective 
networ ks. Networks N1 -N3may in other respects be identical to networ ks N1 -N3 in conventional designs. In the following 
description, any references to networks N 1 -N3 or hosts A and B should be taken as r eferring to the configuration shown 
in Figure 3, unless specified otherwise. 

In this system, there are several modes of operation, numbered and discussed below as modes 1,2, 2A, 3 and 3A. 
Mode 1 uses the configuration of Figure 1. while the other modes all use the configuration of Figure 3. The features of 
the tunnelling bridges TB1 and TB2 (including their program instructions, actions takers etc ) in modes 2- 3 A are, in mode 
t . features of, respectively, hosts A and B. 

Each of the tunnelling bridges TB1-TB3 is preferably implemented in a separate, conventional computer having a 
processor and a memory, as shown in Figure 4 The memory may be some combination of random-access-memory 
(RAM), read-only-memory (POM), and other storage media, such as disk drives, CD-ROMs, etc. The program instruc- 
tions for each of the bridges TB1-TB3 are stored in their respective memories, and are executed by their respective 
microprocessors. The method of the present invention is carried out by a combination of steps executed as necessary 
by each of the processors of the sending host A, the tunnelling bridges TB1 and TB2, and the receiving host B. 

Encryption of data is an important step in the overall method of the invention, but the particular encryption mechanism 
used is not critical. It is preferable to use a flexible, powerful encryption approach such as the Diffie-Hellman method 
(see W. Diffie and M. Heliman. "New Directions in Cryptography", IEEE Transactions of Information Theory, November 
1976). (The use of encryption in connection with IP data transfers is discussed in some detail in applicant's copending 
patent application, "Method and Apparatus for Key-Management Scheme for Use With Internet Protocols at Site Fire- 
walls'' by A. Aziz, Ser. No. 08/258, 344 filed June 1 0, 1 994 ; which application is incorporated herein by reference.) How- 
ever any encryption scheme that provides for encryption by a first machine, which sends the data packets, and decryp- 
tion by a receiving machine, will be appropriate. 

Figure 6 illustrates the method of the invention, and commences with the generation of data packets at the sending 
host A. The user a! host A enters conventional commands for transmitting a file or the like from host A to host B ; and 
the host computer A carries out the standard procedures for breaking the tile down into data packets as in Figure 7, 
each including both the data 410 and a header 400. In the case of transmissions over the Internet, this will be the IP 
header. Though the current discussion will be directed in large part to IP-specific implementations, if should be under- 
stood that any network protocol may be used in conjunction with the present invention. 

A! box 200, the user at host A (see Figures 3 and 6) enters the conventional command for sending the file, email, 
or the like to a recipient, and host A generates data packets for sending over the Internet in the normal fashion. Each 
data packet initially has a structure like that of data packet 400 shown in Figure 7, including a data field 4 1 0 and a header 
field 420. The header 420 includes the destination address, in this example the IP address of host B. 

The data packets are transmitted by host A at box 210, again in conventional fashion. However, at box 220. each 
packet is intercepted by the tunnelling bridge TB 1 (see Figures 3 and 4), when any of modes 2, 2A. 3 or 3A is used 
(see discussion below). When mode 1 (described below) is used, steps 220 and 280 are omitted, since this mode does 
not use tunnelling bridges; instead, the actions taken by the tunneling bridges in modes 2-3A are all accomplished by 
the source and destination hosts themselves in mode 1. Thus, in the following discussion, wherever TB1 or TB2 is 
mentioned, i f should be understood that in the case of mode 1, the same feature will be present in host A or host B, 
r espec' ively 
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Sioieci in the memory oi TBI (oi host A, ioi mode i) is a look-up table (not sepaiaiely shown) of me auai^sses o\ 
hosts, both on the local network Nl and on remote networks such as N2 and N3 ; and an indication (or each network 
whether data packets from or lo that hosi should be encrypted. For instance, in mis case ihe hosts table ot TBI indicates 
that any messages sent from host A to host B should be encrypted. Thus, bridge TB 1 (or host A) looks up hosts A and 
B in its tables, and determines that the data packets to be transmitted must first be encrypted, as indicated at boxes 
230 and 240 ol Figure 6. 

Alternatively: the table couio stoied the network idenuneis (eg oroadcast addicfsses) oi networks l\l"i cuui N2 
indicating that anything sent irorn network Nl to network N2 is to be encrypted. In this case, the table need not list each 
host in each network, which makes the table smaller and easier to maintain. 

If each liost is listed, however, greater flexibility can be retained, since it may be mat messages toot nom par uculcu 
hosts need or should not be encrypted. In an alternative embodiment, the look-up table lists the networks Nl and N2 
as networks to and from which packets should be encrypled : and also includes a hosts section of the table indicating 
exceptions to the normal encryption rule (or these networks. Tnus, if networks Nl and N2 ate listed m the look-up table, 
then packets travelling from Nl to N2 should normally be encrypted: however, if there is an "exceptions" subtable indi- 
cating that no packets from host A are to bo encrypted, then the normal rule is superseded. The exceptions can ol 
course, go Doth ways: where the normal rule is that the packets tor a given network pair should/should not be encrypted, 
and the exception is that lor this given host (source or recipient) or host pair, the packet should not/should nonetheless 
be encrypted. In this embodiment, the small size and ease of maintenance of the network tables is by and large retained, 
while the flexibility o! the hosts table is achieved. 

If the data to be transmitted Irorn host A to host B (oi network IM'i to noiwork N2) should not be trnciyptc-u, u ten mo 
method proceeds directly to step 270, and the packet in question is har ismiued unencrypted to the destination, via the 
Internet (or other intervening network). 

In this example, the packets are encrypted at box 250 This is earned out by me tunnelling onuge "i B I accoro.ny 
to whichever predetermined encryption scheme was selected, the primary requirement being that of ensur ing that TB2 
ts provided with the same encryption scheme so that it can decrypt the data packets TB2 must also be provided in 
advance with the appropriate key or keys for Decryption. ✓ 
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At box 260. ai i encapsulanon neadc-r is appor idea to the ei ici yptea aaia packet Tnis r road or can lake oi ic- oi se^-i a! 
alternative forms, according to the requir ements of the user Several modes of packet modification can be accommodated 
using the same basic data siructui e (but with differences in the information that is appended in the encapsulation header), 
such as the following: 



Mode 



2A 
3 



3A 



Appended information 



Encryption key management information (itself unencrypted) 

New IP header including originally generated IP addresses ol source and destination hosts (enonci yptoUj 
Encryption key management information (in encrypted form) 
Tunnelling bridge identifier tor sender (unencrypted) 

New IP header including broadcast addresses of souice and destination networks (unenciypteo) 
(Same as mode 2, but without the tunnelling bridge identifier.) 
Encryption key management information (encrypted) 
Optional: tunnelling bridge identifier for sender (unencrypted) 

New IP header including originally generated IP addresses oi souice and destination hosts (ur lenci ypteu; 
(Same as mode 3, but without the tunnelling bridge identifier.) 



so 



55 



Data. structures for modes 1, 2 and 3 are depicted in Figures 8 9 and 10, respectively, wherein like leierence 
numerals indicate similar features as described below. The data stiuciuie for mode 2A is illustrated in Figure 11. and 
mode 3A may use the data structure of Figure 8 

The data structure 402 for mode 1 is repieserued in Figure 8. The original data 4 10 and original heaoei 420 aie 
now encrypted, indicated as (410) and (420). Encryption key management information 440 is appended (in encrypted 
form) as part ot the new encapsulation header 430, along with a new IP header 450, including the addresses of the 
source and destination hosts. The information 430 includes indicates which encryption scheme was used. 

Key management information can include a variety ol data, depending upon the key management ana encryption 
schemes used. For instance, it would be appropriate to use applicant's Simple Key-Management for Internet Protocols 
(SKIP), which is described in detail in the attached Appendix A. 
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In Figures 7-11, the Hotels with reference numerals in parentheses are encrypled, and the other fields are unen- 
crypted Thi is, in Figure 8. !he original data field 410 and address field 420 are encrypted, while the new encapsulation 
header 430, including the key management information 440 and the IP header 450. is not encrypted. 

In this embodiment, the tunnelling bridges TB1 and TB2 might not be used at all. but rather the hosts A and B could 
include all the instructions, tables, etc. necessary to encrypt, decrypt, and determine which packets are to be encrypted 
and using which encryption scheme. Mode 1 allows any intervening observer to identify the source and destination 
hosts, and Ihus does nol provide the highest level of security. It does, however, provide efficient and automatic encryption 
and decypi'on for data packets between hosts A and B. without the need for additional computers lo serve as TB1 and 
TR2 

Alternatively, in mode 1 field 440 could include the IP broadcast addresses of the source and destination networks 
(instead of that of the hosts themselves), and in addition may include a code in the encryption key management infor- 
mation indicating which encryption scheme was used. This information would then be used by an intercepting computer 

(such as a tunnelling bridge) on the destination network, which decrypts the data packet and sends it on to the destination 
host. 

In mode 2. a data structure 404 is used, and includes a new encapsulation header 432. It includes key encryption 
management information 440, which is appended to the original data packet 400, and both are encrypted, resulting in 
encrypted fields (410), (420) and (440) shown in Figure 9. A new IP header 470 including the broadcast addresses of 
the source and destination networks (not the addresses of the hosts, as in field 450 in Figure 8) is appended. In addition, 
a tunnelling bridge identifier field 460 is appended as pan of the encapsulation header 432. Here, fie'ds 4 10, 420 and 
aaq in this embodiment are all encrypled, while fields 460 and 470 are not. 

The tunnelling br idge identifier identifies the source tunnelling bridge, i.e. the tunnelling bridge at the network con- 
taining the host from which the packet was sent. The recipient tunnelling bridge contains a tunnelling bridge look-up 
table, indicating for each known tunnelling bridge any necessary information for decryption, most notab'y the decryption 
method and key. 

An appropriate tunnelling bridge identifier might be a three-byte field, giving 2 24 or over 1 6 million unique tunnelling 
bridge identifiers. An arbitrarily large number of individual tunnelling bridges may each be given a unique identifier in 
this way. simply by making the field as large as necessary, and indeed the field may be of a user-selected arbitrarily 
variable size. If desired, a fou r -byte field can be used, which will accommodate over 4 billion tunnelling bridges, far 
^vr.eeding present needs. 

Using mode 2. any observer along the circuit taken by a given data packet can discern only the tunnelling bridge 
identifier and the IP broadcast addresses for the source and destination networks. 

The IP broadcast address for the destination network will typically be something like "129.144.0.0". which represents 
a oarticular network (in this case, "Eng.Sun.COM") but not any specific host. Thus, at intermediate points on the route 
of the packet, it can be discerned thai a message is traveling from, say, "washinqton.edu" to "Enq.Sun.COM", and the 
identification number of the receiving tunnelling bridge can be determined, but that is the extent of it; the source and 
destination hosts, the key management information, and the contents of the data packet are all hidden. 

Mode 2A uses the data structure shown in Figure 1 1 , wherein the I P broadcast addresses for the source and recipient- 
networks Nl and N2 are included in the encapsulation header field 470, but no tunnelling bridge identifier is used. This 
embodiment is particularly suitable for networks where there is on!v one tunnelling bridge fo r the entire network or 
indeed for several networks, as illustrated in Figure 5. 

In Figure 5 ; a oacket sent from host C to host D will first be sent from network N4 to network N5, and will then be 
intercepted by the tunnelling bridge TB4, which interceots all messages entering or leaving these two networks. TB4 
will encrypt the packet or not, as indicated by its hosts look-up table. The oacket traverses the public network and is 
routed to network N7, first being intercepted by tunnelling bridge TB5 f which intercepts al' messages entering or leaving 
netwo r ks N6-N8), and at that point being decrypted if necessary. 

In this embodiment or any embodiment where a packet is sent from a host on a network where a single tunnelling 
bridge is used for the entire source network or for multiple networks which include the source network, a tunnelling 
bridge identifier is nol a necessary field in the encapsulation header. Since in Ihis case only a given tunnelling bridge 
could have intercepted packets from a given host (e.g., TB4 for host C in Figure 5), the identity of the source tunnelling 
bridge is unambiguous, and the destination tunnelling bridge TB5 will include a table of hosts and/or networks cross-cor- 
related with TB4. Having determined that tunnelling bridge TB4 was the source tunnelling bridge. TB5 then proceeds 
with the correct decryption. 

This approach has certain advantages, namely that it eliminates the need to "name" or number tunnelling bridges, 
and reduces the sizes of the data packets by eliminating a field. However, a tunnelling bridge identifier field provides 
flexibility For instance, in Figure 12. subnetworks N1 1 and N1 2 are part of one larger network N 10, and each subnetwork 
N1 1 and N12 has its own assigned tunnelling bridge (TB7 and TB8. respectively). Thus, subnetworks N11 and N1 2 can 
be subjected to different types of encryption, automatically, and that encryption can he altered at will for one subnetwork, 
withont altering it for the other 
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A packet traveling horn host F 10 i'iosi £ in Figure 12 will include a source tunnelling oridge idenutiei ( 137) so that, 
when it reaches TB6 at network N9, ii is identified correctly as having been encrypted by TB7 and not TB8 In mis way, 
tunnelling bridge TB6 need maintain a table only the information pertaining to the tunnelling budges, and does not need 
to maintain encryption/decryption specifics for the host or network level. (Note that TB6 still maintains information relating 
s to whether io encrypt messages sent between host A and host B or network Nl and network N2 : as the case may be, 
as discussed above.) 

The tunnelling bridge identitiei may be used i'gi a vaiiety oi o trier pui poses i elating to trie source tunnelling bnciye. 
such as statistics recording the numbei of packets received irom that tunnelling bridge, their dates and times ol trans- 
mission, sizes of packets, etc. 

io An alternative to the useoi hosts or networks tables in the memories ol me souice ana destination tunnelling bridges 

(or source and destination hosts, as the case may be) would be any information identifying one or more predetermined 
criteria by which the souice host or source tunnelling bridge determines whether to encrypt a given data packet Such 
criteria need not merely be source and destination information, but could include packet contents, time ot transmission, 
subject header information, user id , presence of a key word (such as "encrypt") in the body ot the packet, oi other criteria 

is Mode 3 uses a data stiuctuie 406 as shown in Figure 10. which is identical to the data structure 402 except lor the 

audition oi field 460 containing the tunnelling bridge identilier. which is the same as the tunnelling bridge identifier dis- 
cussed above relative it mode 2. 

In this embodiment, as in mode 1 : field 450 includes the original host IP addresses lor me souice and destination 
hosts (not the addresses of me networks, as in mode 2), and thus an observer of a mode 3 packet wilt be aole to 

20 determine both the original sender of the data packet and the intended receiver Eithei mode contains sufficient infor- 
mation to loute packets through an internet to a recipient network's tunnelling bridge for decryption and ultimate delivery 
to the recipient host. 

Mode 3A may use the data structure shown in Figure 8 ; in conjunction with a neuvoik coniiguiation such trs tnose 
si own in Figures 3 or 12. The mechanisms ana relative advantages are identical to those described auove tor mode 

2S 2A, while the structure icveals the source and destination host addresses 

Whichever encapsulation header is added at box 260 (see Figure 6) ; the packet ii at box 270. men transmuted to 
trie destination network. At box 280, the destination network's tunnelling bridge (here, TB2 shown in Figuie 3) intercepts 
the packet, which is accomplished by an instruction routine by which all packets are intercepted and inspected for en- 
capsulation header information indicating encryption 

30 Thus, at box 290. the encapsulation header of the packet is read, and at cox 300 it is deteimu led wheihei ti ie packet 

was encrypted. 'If a tunnelling bridge identifier forms a part of the encapsulated packet, then the method of encryption 
and decryption key are determined from the destination tunnelling bridge's (or destination host's, in the case of mode 
1 ) local tables. 

If no encryption was carried out on the packet, then it is sent on without lurtner action to the conect host, as indicated 
■J5 at box 340. Otherwise, its encryption method is determined (box 320), and the packet is decrypted accordingly (box 
330), and then sent on as in box 340. 
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APPENDIX A 

Simple Key-Management For Internet Protocols (SKIP) Abstract 

There arc occasions where i : is advantageous to put authenticity and privacy features at the nct- 
vqt'k layer. The vast rnajcriiy of the privacy and authentication prorccois in the literature deaJ 
^rdi session cnenccd key- n anagement schemes. However, many of the comraonJy used nero/ork 
layer protocols _(e.g IP and E?ng) are session less datagram oriented proceeds. W ft describe a key- 
rnanagement scheme that is particularly we'd suited for use in conjunction unrh a scssion-icss dat- 
agram protocol iiJce CP or EP.ig. We also describe how this pro toco kruy be used in the context of 
Internee tnu Inciting protocols. Tru> 'cey-m^nagerncnf scheme is designed to be plugged into rhc 
IP SecurityProiocol (TPS?) EPn^. 

1.0 Over-vie ^ 

Any kind of scalable and rohusr key-rr^Lnagejienr schema that needs to scajc to the number of 
nodes possible in the Internet needs <o be based on an underlying public-key certificate based 
infrastructure. This is the diiecrion that, e.g. the key-managernenr scheme for secure Internet. 
e-m-iiJ. P^rwzcy Enhanced Mail or PEM fi]. is taking. 

The certificates used by PEM are RSA public icey certificates. Use of RSA public fccy certificates 
ajso enable the establishment of an authenticated session key [2,3]. fBy an RSA public Icey certif- 
icate, whar is meant here is that The key being certified is an RSA public key. 'J 

One way to obtain authenac.rv and privacy at a datagram layer like IP is to use RSA public key 
certificates. (In the follc^inf: description we use the terra I?. although EP is replacabic by IPng in 
rhi? context). 

Tnerc are rw c ways RSA cejnficatcs can be used to provide authenticity and privacy for a data- 
gram protocol The first way is to use ouc-of-band establishment of an authenticated session Scey, 
using one of several session icey establishment proiocois. This session key can then be. used 
so encrypt IP data traffic. Such z scheme has the disadvantage of establishing and maintaining a 
pseudo session sure underneath a session-less protocol. The IP source would need to fin;: com- 
municare ~ir_h the IP desdnarian in order ro acquire this session key. 

Also, as and when tine session key needs to be changed, the I? source and the IP destination need 
to communicate again in ord<:r to aake this happen. Each such communication involves the use of 
a compu tad oral] y expensive public -key n per 3 ri on. 

Tne second way an RSA ccrificate can be used is to do in-band signaJiing of the packet encryp- 
tion key, wher^ the packet encryption key is encrypted in the recipient's public key. This is the 
^ay, e.g, PEM and other public-key based secure e-mail systems do message encryption. 
Although this avoids the ses.-.ion stare establishment requirement, and aiso does not require the 
E'A-o parties to communicate in order to set up 2nd change packer encryption keys, this scheme has 
fhe disadvantage of having to carr~f the pacicet encryption key encrypted in the recipienr'spublic 
key in every packer. 
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Sines an RSa encrypted *c/ would minimaily need to be 54 bytes, and e*n be 12S byics, urns 
scheme mcure the overhead of £4- 12S byres or keying information La ever)' packet, (as time: 
progresses, the RSA block :.ize would need to be close: to 123 bytes sin-ply for sccunr^ reasons ) 
Also, as and when the packet encryption key changes, a public key operation would need to t< 
performed m order to rtcovn tne new packet encryption key. Thus both the protocol and cornpu • 
tationai overhead of such a scnecrie is high. 

10 Use of certified Diffic-HcLhnan (DH) [-] public-keys can avoid the psc^o session >mc establish- 
ment and the commumcatiens requirement between the two ends in order to acquire and change 
packet encrypting keys. Fu: thcrtnore, this scheme does not inctir the overhead of carrying 
64- 12S bytes of keying informs don in every packet. 

7 5 

"i his kind of key-management scheme is tens: suited to protocols like IP, because u eocsn't even 
require ihe remoie side to b; up in order to establish and change packet encrypdoci keys. This 
scheme is described in men: detail below. 

*° 2.0 Simple Key-Mznagem^nt for UiLcrriet Protocols (SKIP) 

We snpuJaue that each IP 0:3 sed iource and destination has a certified Dilfic-Hclirrian public key. 
This public-key is disoribuu: d in the form of a certificate. The certijicacc can be signed using cither 
2S an RSA or DSA sign a aire algorithm. How the certificates are managed is described in more detail 
later. 

Tnus each IP source or dese nadon I has a secret vajuc i. and a public vaJuc g**i mod p. omulariy, 
■jo LP node J has a secret value j and a public value mod p. 

Each pair of iP source and -.iesunarion 1 and J can acquire a shared secret g**ij mod p. They can 
accuire this shared secret without actually having to communicate, as long as the certificate of 
35 each IP node is known :o all the other I? nodes. Since the public-key is obtained from a 

certificate, one narurad way -for ail parties to discover the relevant pubUc-keys is to distribute these 
certificates using a directory service. 

This computable shared secret is used as the basis for a key-ervriypQng-kcy to provide for IP 
40 packet based authentication and encryption. Thus wc caJ! g**ij mod p the long-term score:, and 
derive from it a key Kij. Ki; is used as the key for a shared-key cryptosyscs:m{SKCS) like DHS or 
RC2. 

KJj is derived from g**ij moc p by :akung urte high orcet key-size bus of mod p. Since g~*ij 
mod p is minimally going to be 512 bits and for greater security is going to be 1024 bits or higher, 
we can always derive enough bits for use as Kij which is a key for a SKCS. SKCS key sizes are 
cypicaJly in the range of 40- 256 bits. 

so 

An umocn-aju point here is mat Kij is an irnplici; p-jir-'-ise shared key. It docs not need to be sent 
in every packet or negotiated out -of- bard. Simply by examining the source of an EP packet, the 
destination EP node can compute this shared key Kij. Because this key is implicit, and is used as * 
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master key, its length car: N: made as long as desired, without any ad din on aJ prmncol overhead, in 
order to moke, cryptanalysi'; of Kij ^rhirnriJy difFiculr. 

use Kij to encrypt a trajisJenr key. which call Kp (for panket key). Kp is then used to 
encTypt/auihendcaic an IP packs: or coi]ecdon of packer. Tnis is done ir. order ro limit the acpjai 
amount of data in the iong-xrzn key. Since *c would like co keep the long-term key for a rela- 
nv-ly lone period of rime, say one or two years, we don'? encrvpt the actus] IP data traffic in kev 

Kij. 

Instead we only encrypt astern keys in this long-term key, and use the rr^nsient keys to encrypt/ 
authenticate IP data traffic. Tnis limits the aj^oun; of data encrypted in the long-term key to a rel- 
anvciy small amount e^'en over a long period of dm*, like, sav, one year. 

Tnus the first droe art IP source I, which has a secret value i, needs co communicate with IP desd- 
nation J, which his a secret value j, it computes the shzrzd secret g"ij mod p. It can then dcriv- 
from this shared secret the long-term key ;<jj. IP 50Un:c j ^cn generates a random iey Kp and 
encrypts this key using Kij. h encrypts the relevant portion of the IP packer in key Kp (which may 
« the entire IP packet or jus: the payload of the IP packer depending on the nert-nrotocot field in 
IPSP protected data podon). 

Tne vaJue of tine S AID Seld is used by SXLIP to indicate the mode of processing and to idenrify the 
implicit interchange key. Tpicaj modes coprocessing are encrypird. ercrypTed-amhenrjcaTed, 
3 u ih en dcaicd. compression sic. 

The modes of operadon are identified by the upper 6 bits of the SAID field. The meanings of these 
'jpper 6 bits is specified in section 2.5*be:ow on SAID derived processing modes. The low 22 birs 
of the SAID field are zero. 

if the next protocol field is IR (in other words IPSP is opcradng in encrypied-encapsulaced mode) 
the packet looks as follows. It sends the encrypted IP packet, the encrypted key Kp. encapsulated 

in a dear ouier IF Header. 
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In order to prepare this packet tot -mission on ihc outbound side of IP node ]. no communicator] 
was necessary with IP node J. 

When IP node J receives this packet, it also computes die shared sccre: Kij aj^d caches it tor Lai ct 
use, (in order to do this, if ic didn't already possess I's cenincats, u may have obtained ihis from 
the locaJ directory service; Using Kij u obtains Kp, and using Kp it obLains the originaJ IF packo. 
which it Lhen delivers to the. appropriate place vhich as either a local transport cnary or another 
outbound interface. 

The Message Indicator (MI) ls a field thai is needed id preserve ihc statelessness of the protocol. 
If a single key is used in orr.e: 10 encrypt, multiple packets, (which is highly desirable since chang- 
ing the key on a per packet basis constitutes too much overhead) then the packets need to be 
decrvptabie regardless of !c st or out-of-order packets. The message indicator field serves chis pur- 
pose. 

The actual content of the to I neld is dependent on the choice of SKCS used ioi Kp and irs operat- 
ing mode. If Kp refers to a veck cipher (e.g.. DES) operating in Cipher-Block- Chaining (CSC) 
mode, then the*MI for the nrst packet encrypted in key Kp is the Initial iv.aaon Vector {XV). For 
subsequent packets, the MI is the last btocksizc-bits of ciphertcxt of the lasc (in Sanscrit order) 
packet. For DES or RC2 this would be last 64 bits of the Last packet. For strc&zn ciphers like 
the MI is simply the count c f bytes that have already been encrypted in key Kp (and can be 64 bus 
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long also) 

If the 5 cure e IP node (I in this case) decides :o change the pack-; encryption key Kp, the receiving 
IP node J can discover this :zct u^ithouc having :c perr'orrr a public-key operation. It uses the 
cached vaJue Kij decrypt the eri cryp red packer key Kp. 3-d this is a .shared- key cryp tosysrem 
opcrarion. Thus, ^thoui requiring communication ber^cer minsnarting and receiving; eJids, arid 
Without necessitating the us- of a oublic- Vey crtrsuon, the pricker encrypting key can b*r changed 
by Lhe transmitting side. 

Since the public keys in the certificates are DH public keys, the nodes themselves have no public- 
key signature algorithm. This is not a major problem, since signing on a per-packet basis using a 
public- key crypLosYSierrt is too cumbersome in any case. The in-egriry cf the packets is deter- 
mined in a paired se fasicn using a symmetric cryprosysiern. 

2.1 SK.E? for Packer A uthe: ideation 

In order to achieve authentication in the absence of privacy, SKIP compliant implementations use 
the sncrypted packet key K;o to encrypt a message-digest of the parkei, instead of the packet 
itself. Tnis encrypted diges: is appended at the end of the data portion of the IPS?. As be/ore, Kij 
aJg and Kp aJg identify the :m-'o en cryp don algorithms for keys Kij and Kp. MD aJg is 3 1 byit 
identifier far the message dices' algorithm. 

This mode of opera ti on i c - ii -die a ted by the SAID value ^hich is further specified ir. Scene n 2.x. 
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2.2 Intruder in the Middle A rucks 

Unaudienucatcd DLfne-i-icilnjan is susceptible 10 uiiruder in the rrucdic ansclc. To overcome 
30 this, authenticated Dime- Heliman schemes have been proposed, chat include a signature opera- 

don *'iLh die pardes private signature keys. 

SKIP is not susccpabic 10 intruder in the middle types of aiu-cks. This is because the Djrne-HcJi- 
J5 man public parameters are long- term and cerdried. intruder in the middle aiiacks on Diffic-Hell- 

man assume chat the pardes cannot determine who the public Diffii-HeHman keys belong 
T o. Certified Difne- He lima n public keys eliminate this possibility, without requiring any 
exchange of messages bcrv;en the rwo parties or incurring the computational overhead of large 
exponent exponentiations (e.g.. RSA signatures). 



2.3 Storage or Cached Key ; 

Since LT:- K.ij v allies neen :c be cached for efficiency, reasonable safeguards need to be tikeci to 
protect these keys. 

"Gr.e possible: rvay ;o dvj this is to provide a hard^-aic dc%icc to compute, S'.ore -in a pcrtorra opcra- 
duas using these keys. This device can ensure that there are no i menaces to extract the key from 
the device. 
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2 A Manual Keying 

As an interim measure, in the absence of certification hierarchies, nodes may wish to employ 
m an u aJ 1 y e_xc h an ged key: n \ vn/o ma tio n . To h andle such eases, ih e pair key Ki j c an be th e key 
\h?.: is manually sec up. 

Since manual re-keying is sb^ and awkward process, ir still makes sense co use :he rwo level 
keying srrucrurey-arid encrypt the packets has the same benefit as before, namely it avoids over 
exposing the pair krey which is advantageous to maintain ever reJatively long periods of time. 
"This is particularly crue for high-speed nerwork links, where it is easy to encrypt large axnoum? of 
data over a short period of time. 

2.5 Processing Modes and SAID values 

The upper 6 bus of the SA'D tie id are jseti to indicate the processing roode. The processing 
modes defined so far are, encryption, authentication, compression^ and packret sequencing (for 
playback protection). Since none of these nodes is muruaUy exclusive, multiple birs c*eing on 
indicate the employment of all the relevant processing modes. 

SAID bits 

Sit 22 Sir. 23 Sin 24 Bit 25 Sic 25 Biz 21 
■* , + 

I Encrypted I *.~fc henries ted I Compressed I 5eqvj*»nr.?d { Savd i Ravd 1 



Bit 22 = 1 if packet is encrypted, 3 ir 22 = 0 otherwise 

Bit 23 = 1 if packet is authenticated, Bit 22-0 otherwise 

Bit 24 = 1 if packet is compressed before encryption, Bit 2* = 0 other-arise. 

Bit 25 = I if packets arc sequenced. Bit 25 - 0 otherwise 

Bits 26 and 27 axe reserved for future use, and shall be 0 until specified. 

For erampie. to indicate i> ar a packet ;> er.crypTe.-1 and authenticaTcd, Bits 22 and 23 shaij be one. 

2 0 SKIP far Multicast IP 

It is possible to use this kind of scheme in conjunction with datasram multicasting protocols lijce 
IP (or EPng) muincast [5]. This requires key -management awareness in ths esiabhshmen: and 
jo-ining process of multicast groups. 

In order to di srribuie multicast keying material, rhe notion of a group ov^ner ne^ds to exist. When 
secure multicasting ro multicast address M is required, a group membership creation prrimitive 
will need to establish the fxoup scene: vaJ-e Km and :hc membership "ist of addresses that are 
allowed -o rransmir and re-zeivc encrypted muincast datagrams to and from group addne?.s M. 
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The groep key Km is not us.'d ^ a packet encryption key, but raiher as the -roup lmcrcrvdnse Key 
(IK). 

5 Nodes wishin? id raisraii/i :cei<. e encrypted diagrams 10 mulacasc address M need co aeq^jc 
the gro-p EK Km. This is dene by sending in encrypted/aufcenricated roques: to join pp.Tmove.'.o 
the group o*-ner. If the requesting node's address is pan of the group s membership, then mc 
group owner ^11 send the I< Km, and associated litcdmc information m an encrypted packiii, 

'° using the pair^ise-secure protocol described in Secoon 2 above. 

Transmit nodes co group, address M will randomly genera P^kcc ciicryprion key, Kp, arid 
encrypt ihese keys using Kr.,. The packee s<r,crure is similar co the structure used icr cnciypiec 
,5 unicasc IPSP Dockets, excep : tec the face thai ihc packet keys Kp are not encrypted >n me p^x-w^c 
keys Kij. but instead are enc:rypied using the ^roup IK Kru. An example encrypteo mulacasi 
packet is shown below. 
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There are i^'O cusaric; ad villages oi mis scheme. Fust, every member of the aiuldcasi group ca.n 
change packet encrypaon k:ys ^ ofien as it desires, vvu^out involving k*y-setup cocnmunicanons 
overhead involving every nierabe: of the group. 

Second since all the parke: encryrp ion keys are different, mere is no, problem in using sacarn- 
ciphers'swh multicast. This is because each sooice of encrypted rarac uses a different key-srre^D 
and thus there is no kcy-siniarn reuse problem. If ail members of the raulacist group used die 
same packet encrypnon key (as c.g stipulated in the current drafc of $02. 10 key-rr.ana-cmcnt). 
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the- '<cy- seeded srrearn ciphers ecu Id not be used with rouldcasc 

How- the identity of the grot'p owner is established and corximunicated \o the participating nodes is 
left to :he application layer. Hn^rver, th.ii alv3 needs io dorr, in ? secure fn?h.iop. othcrwrse the. 
underlying Vey. manage me -.r facility con be defeated. 

0 Man a genie n " of DH c.e:Tinc2!in 

Since the nodes' public DH values arc c o coin u rue a ted in the form of certiocaics, the same son of 
rnnlti-aer certifies Don srrucrure thai is being deployed for PKM [5] and also by the European 
PASSWORD project can be used. N3mc!y, there can be 3 Top Lcvei Certifying Au:horiry(TLCA) 
which may w C ]] be the sam-i the Internet Policy Registration Authoriry (IPR.A), Policy Certifying 
Authorities (PCAs) a: the S'icond der and organizational CAs below thar. 

In addition to the idendry certificates, which arc whu are part of PEM certifies re infrasrrucrure, 
wc also need additional authorization certificates, in ortirr to properly track the ownership of IP 
addresses. Since we wouid like to directly use IP addresses in Lhe DH certificates. cannot use 
name subordination principles aJone (as e.g used by PEM) in order to dcrcrrnine if a particular CA 
hi? (he authoriry to hind a particular IP address ro a DH public ^alue 

We car. still use the X.509/TEM certificarc formic, since the subject Distinguished Name (DN") in. 
■he certifies re can be the numeric string representation of a lis i of TP addresses. 

Since the nodes only have DH public *eys, which bavs no signarure capability, Lhe nodes axe 
themselves unable 10 issue :rrtifica;es. This Cleans that there is an aigoriihmic termination of a 
certificate path in a leal' roc.:, unlike the certificate hierarchy employed in. e.g PEM, where every 
leaf node is potentially a rc<fuc CA. 

The node certificates arc issued by organizational CAs which have jurisdiction over the range of 
IP addresses that are being certified. The PC As will have ro perform suitable checks (in line v^th 
che advertised policy of that PCA) ro confirm that the organization which has jurisdiction over a 
range of addresses is issued 3 certificate giving if the authoriry to certify the DH values of individ- 
ual nodes with those addresses. This authoriry will be delegated in the form of a authorization cer- 
tiheare signed by the PCA. For the purposes of authorization, the CA's Distinguished Name (DN) 
N*nll be bound to the range of IP addresses o^cr which it has jurisdictior.. T^e CA has either an 
PSA or D5A certincare ns :ed by the PCA. 

An authorization certificarc: will also contain in forma don about whether the CA to whom author- 
icy is being delegated can sj'o- delegate thai authority. Tie CA which has defegaubie authority 
over a range of EP add res se ; can delegate authoriry ever pan of the range to a suborcbnaie CA, by 
si^nin^ another authorization certificate using its own prrore kzy. If the authority is ncn-dclcgaf- 
ahlc. then the CA cannot delegare author! fy for th.ir nn^ of add.-re.sses. 

Tne range of IP addresses ;re identified in the authori zari-on certificate in the form of a lis: of IP 
address prefer, length pair: 
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5.0 X.509 Encod:ng of SKJ? DH cemiicaies 

5. 1 Encoding of DH public values 

The encoding of a DH pub! tc value in in X.5OT cmincaie wiii be in <-hc lorn: of aji 
The algorithm lodcnaficr uiU be as defined in PKCS »3 [7]. Thus 



and from PKCS ff3, 

Aicaric .irrvl a « ri e; i 1 1 c r 



SEQUENCE [ 

.llgozlLn.ii OBJECT IDENTIFIER 

SEQUENCE { 

pri.rr-a Z.^TEGEK, P 

bat.e INTEGER, g 

privaiaVaJu£U-?t^ INTEGER Ot-TiONAi. 



wi:h ihc OBJECT IDENTIFIER value c*ing 

ci>i.<<iyA9 = fienvonc. OBJECT IDENTIFIED 

{isotl; Mfri»ei:-body (2) U3{8VJ) 

Vr-nich is also i^jccn from PKCS H3. 

DHPublicKcy is what gcis encapsulated as the BIT STRING in Subjcc u^itilicKcyLnfo of an 
X.509 ccruficaLc in the obvious manner. 

5.2 Encoding oi the Dxsan juished Name (DM) 

The c-mfiCaLc is allowed bind multiple IP addresses to a sin*ie public viduc ^ ^cornn^^c 
cscs where a single LP nak has muldpie IP addresses. T^e SEQUENCE OF consiruct in a DN 
readily allows for this. Whac is needed is an OBJECT IDENTIFIER, for an AccnbuieTypc spcciiy- 
ing an IP addr-ss. "This is c.ehncd hert as, 

ioA ddr* 3a ATTRIBUTE "ITH ATTK.1BUTE-SWTAX 

?ri.r.:AEls3:ring ( S I 7.E (1 . . ub-ip*ddr e:a a ) ; 
: : - ilpacc-oid 1) " H«^d co ro-jiacer this XXX 

"n* ON- I:-. ft* cerciflcile can cor. din ! l i>.< i< 

of ihese by iisrad/ig 0:1 the SEQUENCE OF cons^ua of the Relative 
Distinguished Name Sequence. 
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The Printable string contain:: either the hexadecimal reprrwitaaon or standard tier notation repre- 
sentation of an fP address. 

5 ~ Encoding or ,m Authorisation Certinca:e 

An authorization certiScate is associated with -*ach CA be lew the PCA Sr.vei. The authorization 
certificate in effect entitles CA to bind IP addre?s?.S *o DH public key?. 

6 0 Conclusions 

Wc have described a schema. Simple Key- Management for Interne: Protocols (SKIP) thai is par- 
ticularly well suited :o connectionless datagram protocols like IP and its replacement candidate 
SI? P. Both the protocol and computational overheads of this scheme arc relatively low. In-barid 
signaled keys incur the length overhead of the block size of a shared-key cipher. Also, serring and 
changing packet encrypting keys involves only a shared-key cipher operation. Yet the scheme has 
the scalability and robustness of a public- key certificate based infra structure . 

A major advantage of this s :heme is that establishing and changing packer encrypting keys 
requires no cornmuni cation between sending and receiving node? and no estabiishmenc of Z 

pscudo- session stale between the r^*o side.' is required. 

In many ways the key-manr.gemenc scheme here has structural similarities with the scheme used 
by ?EM ( i]. Both use the concept of an intcr-changs key (in our case that is the pair keys Kij) and 
data encrypting keys (the packet encryption keys Kp). By using the implicit shared secret prop- 
erty of long-term DH public: values, and treating the resulting keys as keys for a SKCS, wc have 
reduced the protocol overhead substantially as compared to the overhead of PEM when used in 
conjunction with an asymmetric key- management system . 

We have also described ho'^ this scheme may be used in conjunction with datagram multicast 

protocols, allowing a single encrypted datagram to be multicast to all the receiving nodes. 
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Claims 

30 1. A method loi iransn nuir.g ana leceiving packets oi data via an inierneiwoik nom a lirsi host computei on a inst 
computer network to a second host computer on a second computer network, the first and second computei networks 
including, respectively, first and second bridge computers, each of said lirsi and second host computers and first 
and second bridge computers including a processor and a memory tor storing instructions for execution by the 
processor, each of said first and second bridge computers further including memory storing at least one predeter- 

J5 mined encryption/decryption mechanism and information identifying a predetermined plurality of host computers as 

hosts i equiring security for packets transmitted between them, the method being carried out by means of the instruc- 
tions stored in said respective memories and including the steps of: 

(1) generating, by the iiist host computei.. a lirsi data packet ioi transmission to the second nasi computei, a 
40 portion of the data packet including information representing an internetwork address of the first host computer 

and an internetwork address of the second host computer; 

(2) in the inst bridge computei.. intercepting the lust data packet and determining whethei me nrst and second 
host computers are among the predetermined plurality ot host computers tor which security is required, and it 

45 not, proceeding to step 5, and it so, proceeding to step 3; 

(3) encrypting me lust oata packet in me lirsi bridge computei; 

(4) in the lust biidye con'iputei, yenoiaiing and appending to the lirst data fjackei an ei lapduiatiui i headvji ; 
so including: 

(a) key management imon nation ideniilying the predetermined encryption method, and 
(u) a new address header lopresenting the souice and destination ioi the data packet 
thereby generating a modihed data packet. 

(5) nansrniiting the data packet from the liisi ondge computei via me miemeiwoik u; me Sc-cono compi 
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network - 

(6) inierr.epi'ng the data nickel at I hp; second bridge compute^: 

(7) in the second bridge computer, reading the encapsulation header, and determining therefrom whether the 
data packet was encrypted, and if not. oroceeding to step 10. and if so. proceeding to step 8: 

(8) in the second bridge computer, determining which encryption mechanism was used to encrypt the first data 

packet: 

(P) decrypting the first data packet by the second bridge computer; 

( 10) transmitting the first data packet from the second bridge computer to the second host computer: and 

f i 1 ) receiving the unencrypted data packet at the second host computer. 

7 he method of claim 1, wherein the new address header for the modified data packet includes the internetwork 
broadcast addresses of the firs! and second computer networks. 

The method of claim 2, wherein the new address header for the modified data packet includes an identifier of the 
second budge computer 

The method of claim 1, wherein the new address header o f the modified data packet includes 'he address o r the 
second host computer 

The method of claim 4, wherein the new address header for the modified data packet includes an identifier of the 
second bridge computer 

A system for automatically encrypting and decrypting data packets transmitted from a first host computer on a first 
computer network to a second host computer on a second computer network, including; 

a first bridge computer coupled to the first computer network for intercepting data packets transmitted from 
said first computer network, the first bridge computer including a first processor and a first memory storing instruc- 
ting for executing encryption of data packets according to a predetermined encryption/decryption mechanism; 

a second bridge computer coupled to the second computer network for intercepting data packets transmitted 
to said second comouter network the second bridge computer including a second processor and a second memory 
storing instructions for executing decryption of the data packets; 

said first host computer including a third processor and a third memon/ including instructions for transmitting 
a first said data packet from said first host to said second host; 

a table stored in said first memory including a correlation of at feast one of the first host computer and the first 
network with one of the second host computer and the second network, respectively; 

instructions stored in said first memory for intercepting said first data packet before departure from said first 
network, determining whether said correlation is present in said table, and if so, then executing encryption of said 
first data packet according to said predetermined encryption/decryption mechanism, and transmitting the first data 
packet on to the second host computer; 

instructions stored in said second memory for intercepting said first data packet upon arrival at said second 
network, determining whether said correlation is present in said table, and if so, then executing decryption of said 
first data packet according to said predetermined encryption/ decryption mechanism, and transmitting the first data 
packet to the second host computer 

The method of claim 6, wherein the new address header for the modified data packet includes the internetwork 
broadcast addresses of the first and second computer networks. 

The method of claim 7, wherein the new address header for the modified data packet includes an identifier o f the 
second bridge computer 

The method of claim 6, wherein the new address header o f the modified data packet includes the address of the 
second host computer 
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10. The method oi claiin 9, wnerein the new address header ioi the mourned data packei includes an idenwiei oi the 
second bridge compuier. 

I I. A method ioi tiansinitung and receiving packets oi daia via an internetwork nont a in si hosi compuiei on a in si 
computer network lo a second hosi computer on a second compuiei network, the first and second computer net- 
works, each of said tirst and second host computers including a processor and a memory for storing instructions 
for execution by the processor; each said memory storing at least one predetermined encryption/decryption mech- 
anism and a source/ destination table identifying a predetermined plurality ol sources and destinations requiring 
security lor packets transmitted between them, the method being carried out by means of the instrucdons stored in 
said respective memories and including the steps of: 

( l) generating, by the in si host computer, a iiisi daia packet for transmission to the second hosi computer, a 
ponion of the data packet including information representing an internetwork address of a source of the packei 
and an internetwork address of a destination of the packet; 

{2} in the lusi host computer, determining wnethei the source and desunanoi r oi me iirstoata packet are among 
the predetermined plurality oi sources and destinations identified in said source/destination table for which 
security is required, and if noi, proceeding to step 5, and if so : proceeding 10 step 3; 

(3) encrypting tne iirsl uaia packet in the iiisihosi computet, 

(4) in the iirsi host computer, generating arid appending to the lu st data packet art encapsulation header, includ- 
ing: 

(a) key management miormanon idciitiiying the pi edctei mined encryption method, and 

(b) a new addiess heauei ideiuiiying the souice and destination ioi me uaia packet, 
thereby generating a modi lied daia packet: 

(5) uansri lilting tr ie data packei nom the first host computer via the internet woi k to the second compuiei net woik; 

(6) in the second nusi compuiei, leading tne encapsulation header, arid deterum uny tneretiom vmethei me 
data packei was encrypted, and ii not, ending the method, and if so, proceeding to step 7; 

(7) in the second host computer, determining which encryption mechanism was useo to encrypt the in si data 
packet; and 

(8) decrypting the lirst data packei by the second host compuiei 

12. Themeit iodoi ciami 11. wherein the new address header lor the modified daia packei includes internetwork bioad- 
cast addresses of ihe first and second computer networks. 

1.3. The metnod oi claim 1 1 , wneiein me source/destination table includes oaia loeuiiiying internetwork aooiesses ot 
the lirst and second host computers. 

14. A system lor automatically encrypting and deciyptmg data packets transmuted norn a lust nost compuiei on a nisi 
computer network and having a Iirsl processor and a first memory, via an internetwork lo a second host compuier 
on a second computer net woik and having a second processor and a second memory, the system including: 

security data stored said first and memories indicating that data packets meeting al least one predetermined 
criter ion are lo be enciypted; 

a predetermined encryption/decryption mecnanism stored in said fust and second memoi ies; 

a decryption key stored in said second memory; 

instructions stored in said first memory for determining whether to enciypt daia packets, by oetei mining 
whether said predetermined criterion is met by said data packei; 

instructions siored in said lirst memory tor executing encryption accoiaing 10 said pi edetem uned enciyp- 
lion/decryption mechanism of at least a first said data packei, when said criterion is met. and for appending an 
encapsulation header to said first data packet and transmitting said first daia packet to said second host, said 
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encapsulation header including at least an unencrypted destination address for said first data packet; 

instructions stored in said second memory for receiving said first data packet, determining whether it has been 
encrypted by relerence to said security data, and if so then determining which encryption'decryofion mechanism 
was nsrd for encryption and decrypting said data packet by use of said decryption key 

The system of claim 14, wherein: 

said security data comprises correlation data stored in each of said first and second memories identifying at 
least one of said first host computer and said first network correlated with at 'east one of said second host computer 
and said second network; 

the system further including instructions stored in said first memory for determining whether to encrypt data 

packets by inspecting for a match between source and destination addresses of said d^fa packets with said corre- 
lation d^ta. 
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(57) A system ioi automatically encrypting and de- 
crypting data packet sent from a source host to a desti- 
nation host across a public internetwork. A tunnelling 
bridge (TB) is positioned at each network (N), and inter- 
cepts all packets transmitted to or from its associated 
network The tunnelling bridge includes tables indicated 
pairs of hosts or pairs oi networks between which pack- 
. ets should be encrypted. When a packet is transmitted 
from a first host, the tunnelling bridge of mat host's net- 
work intercepts the packet, and determines from its 
header information whether packets from that host that 
are directed to the specified destination host should be 
encrypted; or, alternatively, whether packets irom the 
source host's network that are directed to the destina- 
tion host's network should be encrypted. If so, tne pack- 
et is encrypted, and transmitted to the destination net- 
work along with an encapsulation header indicating 
source and destination information: either source and 
destination nost addresses, or the broadcast addresses 
of the source and destination networks (in the latter 
case : concealing by encryption tne hosts' tespective ad- 
dresses). An identifier of the source network's tunnelling 
bridge may also be included in the encapsulation head- 
er. At the destination network, the associated tunnelling 
bridge intercepts the packet, ii ispects the encapsulation 
header, from an internal table determines whether the 
packet was encrypted, and from either the source (host 
or network) address or the tunnelling bridge identifier 
determines whether and how the packet was encrypted. 



• II the packet was encrypted; it is now oecrypied using a 
key stored in the destination tunnelling bridge's rnernor y, 
and is sent on to the destination host. The tunnelling 
bridge identifier is used particularly in an embodiment 
where a given network has more man one tunnelling 
bridge, and hence multiple possible encryption/decryp- 
tion scnemes and keys. In an alternative embodiment, 
the automatic enci yption and decryption may be carried 
out by the source and destination hosts themselves, 
without the use of additional tunnelling bridges, in which 
case the encapsulation header includes the source and 
destination host addresses. 
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